6.07. История аналитики
История аналитики
Аналитика как способ познания и принятия решений существовала задолго до появления компьютеров - собственно, в древности люди тоже анализировали данные. Пример - учёт урожая, распределение ресурсов, военные стратегии. Это всё аналитика, но современное понимание этой науки отличается от классического, особенно в контексте информационных технологий, и формировалось оно постепенно, под влиянием развития науки, экономики и техники. Аристотель имеет два сочинения - «Первая Аналитика» и «Вторая Аналитика», и это были просто рассуждения с логическим мышлением. Здесь важно отметить, что Аристотель называл формальную логику «аналитикой», а слово «логика» стали использовать позднее, после его смерти.
Поэтому да, аналитика существует ещё с древнейших времён.
В начале XX века термин «аналитик» ассоциировался с бухгалтерами, экономистами и статистиками - специалистами, которые обрабатывали данные для прогнозирования, выявления тенденций, оптимизации процессов и поддержки управленческих решений. Эти профессионалы анализировали финансовые отчёты, рыночные показатели и производственные циклы, но их работа была в основном ручной и не связывалась с автоматизированными системами (всё правильно, ведь систем не было!). В зависимости от области деятельности, аналитики работали в финансах, маркетинге, медицине, научных исследованиях и даже промышленности.
И представьте, как нужно было прогнозировать? Перед вами выгружают вагон с отчётами, которые писались вручную различными филиалами или подразделениями, и нужно было всё это изучить, структурировать, систематизировать, подготовить сводку, сделать выводы, какие-то прогнозы и в конце концов резюмировать это всё. Грязная работа, которая «выручает» начальников и руководителей, которым главное - понимать, куда всё идёт. Именно поэтому «бухгалтера» были приближенными в любом бизнесе, ведь они сочетали эти функции, порой и без специально выделенных для этого людей. Причем это только финансовые показатели, порой требовалось анализировать чужие отчеты, результаты деятельности конкурентов, чтобы понимать, у кого имеются полезные решения. Тем не менее, этим и занимается аналитик - сбор данных из различных источников, обработка этих данных от ошибок, дубликатов, пустых значений, формирование выводов и предложений.
Поэтому можно сказать, что сначала аналитики были именно финансовые и маркетинговые. Но мир, бизнес и экономика стремительно развивались - с появлением каждой новой технологии или изобретением устройств, отрасли менялись, и требовалось во всё это погружаться.
С приходом эпохи компьютеров в середине XX века ситуация уже изменилась, ведь в 1950-1960-х годах первые ЭВМ начали внедряться в государственные и корпоративные структуры, и возникла острая потребность в людях, способных «переводить» бизнес-задачи на язык машин. Тогда и появился термин «системный аналитик» (system analyst). Его роль заключалась в том, чтобы понимать как бизнес-требования, так и технические возможности систем, выступая посредником между заказчиками и программистами.
Первые системные аналитики, разумеется, были инженерами или математиками, ведь вся вычислительная сфера была связана именно с ними. Это потом они переквалифицировались в IT окончательно. Они проектировали архитектуру систем, определяли потоки данных, разрабатывали спецификации - всё это требовало глубокого понимания как логики бизнеса, так и принципов работы программного обеспечения. Появление понятия «бизнес-логика» стало естественным следствием, ведь это та часть системы, которая отражает правила, процессы и политики организации, отличные от технической реализации.
К 1980-1990-м годам, с ростом сложности программных продуктов и масштабов автоматизации, роль аналитика стала более специализированной. Разделение труда привело к появлению нового термина «бизнес-аналитик». В отличие от системного аналитика, фокусировавшегося на технических аспектах, бизнес-аналитик сосредоточился на изучении потребностей бизнеса, моделировании процессов, сборе и документировании требований. Он стал ключевой фигурой на стыке управления и технологий.
Изначально понятие «аналитик» в IT считалось производным от других профессий и не имело чётких границ. Только к началу 2000-х годов, с развитием методологий управления проектами (PMBOK, PRINCE2) и стандартов вроде BABOK (Business Analysis Body of Knowledge), профессия бизнес- и системного аналитика окончательно оформилась как самостоятельная дисциплина с собственными компетенциями, сертификациями и карьерными траекториями.
Так что профессия аналитика в IT имеет двоякое происхождение - аналитик сам по себе существовал с древности, системный аналитик был больше математиком, а бизнес-аналитик и вовсе новая профессия.
И если первые компьютеры были именно академическими инструментами, а техногиганты изначально заключали контракт с небольшими компаниями с всего несколькими разработчиками, процесс был совсем иным, как и подходы к разработке - всё было хаотично, так как они были первооткрывателями. Позднее, с ростом индустрии и увеличением количества компаний разработчиков, стало очевидно, что одним договором, устными встречами и простыми текстовыми описаниями требования описывать уже недостаточно. Нужны были какие-то унифицированные языки моделирования, которые бы позволяли визуализировать процессы, структуры и поведение систем. Именно здесь на сцену вышли стандартизированные нотации, ставшие инструментами профессионального аналитика.
Когда заказчик (инициатор) формирует идею, она, как правило, устная и размытая, но содержащая основную цель и бизнес-логику. Но когда дело доходит до документирования таких целей, в игру вступают юристы - а юридический язык крайне тяжелый, ведь он избегает «лишних слов», и действует исключительно с целью «засудить» и «защититься от суда», словом, прикрывает задницу. Но дайте юридический документ математику - он поседеет! Поэтому аналитику приходилось «расшифровывать» такие документы, рисовать для себя более наглядную модель и описывать документацию. Каждый рисовал, ведь одно дело общие требования, но когда тебе нужно формировать архитектуру решения, из документа легко вытащить лишь сущности, а связи между ними - куда сложнее. Поэтому рисовалась схема связей между сущностями, но каждый делал это по своему, без единого подхода.
В середине 1990-х годов был разработан UML (Unified Modelling Language), ставший результатом объединения нескольких подходов к объектно-ориентированному моделированию. Ключевые фигуры — Грейди Буч, Айвар Джекобсон и Джеймс Рамбо (образовали так называемую «Банду трио»). В 1997 году UML был официально принят OMG (Object Management Group) как международный стандарт. UML позволил аналитикам и разработчикам описывать архитектуру ПО с помощью диаграмм: вариантов использования, классов, последовательностей, состояний и других. Это резко снизило недопонимание между командами.
BPMN (Business Process Model and Notation) появился позже, в начале 2000-х. Конкретно, BPMN 1.0 изначально разрабатывался Business Process Management Initiative (BPMI), а в 2005 году был передан OMG, который официально стандартизировал его. BPMN стал «языком» для описания бизнес-процессов в наглядной, графической форме. Благодаря простоте восприятия и богатой семантике (шлюзы, события, потоки) он быстро стал стандартом в бизнес-аналитике, особенно в банках, логистике и государственных структурах - сейчас это стандарт BPMN 2.0, появившийся в 2011 году.
Стандартизация этих и иных нотаций (вроде ERD (Entity-Relationship Diagram) для моделирования данных, DFD (Data Flow Diagram) и IDEF) означала, что аналитик больше создавал общепонятные артефакты, которые могли использоваться на всех этапах жизненного цикла ПО: от анализа требований до тестирования и сопровождения.
То есть, без аналитики, раньше разработка ПО частенько начиналась с кода, программисты понимали задачу «на слух», и сразу приступали к реализации. А как мы помним, зачастую источником задачи был именно заказчик. Это приводило к множеству ошибок, переделок и «неправильным» продуктам. Далеко ходить не надо - фрилансеры с заказами, техническое задание которых ограничивалось фразой «сделай мне сайт», понимают, о чём я. Позднее аналитик стал ключевой фигурой на старте проекта, ведь именно он собирал, уточнял, моделировал, документировал и координировал, что делало процесс системным. Особенно важной аналитика стала в условиях высокой стоимости ошибок. Чем позже обнаруживается ошибка в требованиях, тем дороже её исправление. По оценкам IEEE и исследованиям Standish Group, исправление ошибки на этапе эксплуатации может быть в 100 раз дороже, чем на этапе анализа.
История IT полна примеров катастроф, вызванных игнорированием аналитики. Можно выделить два ярких случая.
Первый - проект NHS Connecting for Health (Великобритания, 2002–2013), одна из самых масштабных неудач в истории государственных IT-проектов. Целью ставили создать единую электронную медицинскую систему для всей Англии, проект стоил более 12 миллиардов фунтов стерлингов, но был закрыт с минимальными результатами. Причинами провала были такие проблемы, как отсутствие чёткого анализа потребностей врачей и больниц, непродуманная архитектура, пренебрежение бизнес-процессами здравоохранения, слабая роль аналитиков на начальных этапах. Вместо глубокого анализа внедрялись «коробочные решения», которые не работали в реальных условиях. Работавшие в государственных структурах поймут, о чём речь - «добровольно-принудительное внедрение» без учёта интересов.
Второй - крах системы учёта труда в компании Hewlett-Packard (2010). HP внедряла новую систему учёта рабочего времени для 65 000 сотрудников. Проект провалился: система не учитывала локальные особенности стран, правила начисления оплаты были ошибочны, что привело к неверным выплатам и судебным искам. Причины - недостаточный анализ требований в разных регионах, отсутствие моделирования бизнес-логики, недооценка роли бизнес-аналитиков при глобальной автоматизации.
Что забавно, проблема игнорирования или недооценки важности аналитики существует всегда - практически на каждом проекте заказчику нужно «быстрее», он продавливает именно свою точку зрения и собственное видение, которое порой бывает рискованным или необдуманным. Если он продавит, и решение окажется неудачным, он всё равно обвинит команду разработки, что это они всё криво сделали. Сегодня аналитики есть везде, а этап разработки часто может быть короче, чем этап аналитики, ведь это снижает неопределённость, минимизирует риски и повышает шансы на успех проекта.